Application service provider based redundant archive services for medical archives and/or imaging systems

ABSTRACT

A preferred embodiment of the present invention provides a method and system for application service provider based redundant archive services for medical archives and/or imaging systems. In a preferred embodiment, the system comprises a data source providing medical data, a status monitor for controlling the transfer of the medical data from the data source to a remote data store, and a remote data store receiving the medical data and storing the medical data. Additionally, the remote data store may restore the medical data to the data source. Also, the remote data store preferably may transfer the medical data to a second data source. Preferably, the remote data store is an application service provider.

CROSS REFERENCE TO RELATED APPLICATIONS (IF APPLICABLE)

[0001] Not applicable.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH & DEVELOPMENT (IFAPPLICABLE)

[0002] Not Applicable.

BACKGROUND OF THE INVENTION

[0003] The preferred embodiments of the present invention generallyrelate to data storage and retrieval systems, and in particular relateto a method and system for Application Service Provider (ASP) basedredundant archive services for medical archives and/or imaging systems.

[0004] Healthcare practitioners, such as physicians, nurses, assistants,or technicians, for example, employ medical data for diagnosis andtreatment of patients. For example, healthcare practitioners may usemedical data such as medical images, medical reports, applications, andother data, for example, to diagnose and treat patients. Medical datamay be obtained from direct examination, from other healthcarepractitioners, from medical diagnostic equipment, and/or from othersources, for example.

[0005] Medical data may be stored in a local database at a healthcarefacility, such as a hospital, clinic, doctor's office, or other medicaloffice, for example. Storage of medical data in a local database mayenable the medical data to be used in diagnosis and treatment ofpatients. That is, storage of medical data in a local database mayimprove access and retrieval of data for diagnosis and treatment.Medical data may be stored in a local database such as a PictureArchiving and Communication System (PACS).

[0006] A PACS may be used to obtain, store, and distribute electronicimages, such as electronic medical diagnostic images. A PACS may allowimages to be archived in electronic form in a central location on site.A PACS may also allow images to be shared among different users becausethe images are locally centralized and able to accessed at numerouspoints on site. Convenient access to patient data through a PACS mayimprove individual hospital workflow by eliminating the need tophysically transfer images and by providing multiple viewing stationsfor imaging results.

[0007] Typically, data stored in a PACS is stored as DICOM data. DICOMstands for Digital Imaging and Communications in Medicine. DICOM is astandard for image and information transmission. DICOM relates to thetransfer of electronic data between medical diagnostic and imagingsystems. The DICOM protocol may be employed in communication betweenmedical devices and a PACS. The DICOM standard enumerates a command set,data formats, interface specifications, communication protocols, andcommand syntax. The DICOM standard does not specify details ofimplementation.

[0008] Increasingly, healthcare practitioners are relying on the PACSand other digital environments for diagnosis and treatment of patients.As customers become more reliant on digital environments, there is needfor greater backup and redundancy capabilities for digital medical data.There is a need for a source that satisfies the need for greater backupand redundancy through cost-effective and easily managed methods.

[0009] Centralized access to medical data may also improve diagnosis andtreatment of patients through ease of retrieval by multiple users and/ormultiple locations. In the field of computers, Application ServiceProviders (ASPs) have been employed to allow for centralized access andstorage of data. ASPs operate as hosts for data and applications.Typically, ASPs maintain applications and data in an offsite datacenter. ASPs have been hired by companies in the field of computers tomanage data and computer applications. Companies may access data andapplications via an ASP. Typically, in the computer field, companiesremotely access data and applications via an ASP central data location.

[0010] In the field of computers, ASPs may offer several desirableservices, such as secure data storage, data backup, and redundantsystems. Because ASPs offer such services, a customer of an ASP may nothave to incur additional expenses for its own security, backup, andstorage systems. In addition to functioning as a remote database, ASPsmay host a number of applications that may be activated or accessedremotely by customers. By concentrating computing power and maintenanceat the ASP, the ASP may offer continuous access to and support of theapplications and alleviate the need for the customer to purchase andmaintain its own expensive computer equipment.

[0011] For example, ASPs may provide installation, management, andsupport of applications and storage of data for many remote clients.Client data may be stored at a remote data center. Data may be retrievedfrom a remote data center via a communications medium such as theInternet or a private network. Additionally, ASPs may deliverapplications such as email systems, resource planning systems, customerrelationship management systems, human resource management systems, andproprietary applications to remote clients.

[0012] Access to medical data may improve diagnosis and treatment ofpatients by healthcare practitioners. For example, healthcarepractitioners may employ medical diagnostic reports and images inaddition to direct examination of the patient by the healthcarepractitioner. Additionally, multiple healthcare practitioners may accessmedical data for diagnosis and treatment of patients. Thus, there is aneed for access to medical data to aid in medical diagnosis andtreatment of patients by supplementing the healthcare practitioner'sexamination.

[0013] Additionally, reliability of access, storage, and/or retrieval ofmedical data may improve diagnosis and treatment of patients byhealthcare practitioners. That is, if medical data is lost or corrupted,diagnosis and/or treatment of a patient may be impaired without reliableretrieval of medical data. Reliable access to medical data may help toensure that patients may be accurately and timely diagnosed and treatedby healthcare practitioners. For example, protection against corruptionor loss of medical data ensures that the medical data may be availablefor use by a healthcare practitioner in diagnosing and/or treating apatient. Thus, there is a need for reliability in the storage of medicaldata to improve diagnosis and treatment of patients.

[0014] Currently, backup systems for local databases in healthcarefacilities are typically local backup systems. Local backup systems maybe expensive for individual healthcare facilities. Additionally, localbackup systems may require time, money, and personnel to maintain. Thus,there exists a need for a centralized archive for medical data.

[0015] Thus, there is a need for redundant secure storage to guardagainst data loss. That is, redundant secure storage reduces thelikelihood that a patient will have to return to the healthcare facilityand be re-examined to replace images and other examination data in theevent of data loss and/or corruption. Additionally, there is a need fora system that can repair or replace lost and/or corrupted data in theevent of data loss or system failure. That is, a system that can repairor replace data in the event of data loss and/or corruption reduces theprobability that a patient will be re-examined at a healthcare facilityto replace lost and/or corrupted images and other examination data.There is also a need for easier data manipulation and/or preservationbetween medical diagnostic system upgrades. For example, there is a needfor a system to reduce manual transfer and/or re-creation of data,applications, and/or operating system information between an old medicaldiagnostic or storage system and a new or replacement system.

[0016] Thus, a need exists for storage of data to improve reliability ofaccess to medical data for patient diagnosis and treatment.Additionally, there is a need for retrieval of medical data to improvereliability of access to medical data in the event of data corruption orloss. There is a further need for ease of copying data to improveinstallation and configuration of medical diagnostic and/or storagesystems.

BRIEF SUMMARY OF THE INVENTION

[0017] A preferred embodiment of the present invention provides a methodand system for application service provider based redundant archiveservices for medical archives and/or imaging systems. In a preferredembodiment, the system comprises a data source providing medical data, astatus monitor for controlling the transfer of the medical data from thedata source to a remote data store, and a remote data store receivingthe medical data and storing the medical data. Preferably, the medicaldata is transferred at a definable interval. In a preferred embodiment,the definable interval may be a timed interval, an event-based interval,and/or a manual interval. Additionally, the remote data store mayrestore the medical data to the data source. Also, the remote data storepreferably may transfer the medical data to a second data source.Preferably, the remote data store is an application service provider.The system may also include a status monitor for monitoring operationsbetween the data source and the remote data store. Additionally, thesystem may include an access authenticator for authenticating access tothe remote data store.

[0018] In a preferred embodiment, the method includes transferringmedical data from a data source to a remote data store and storing themedical data at the remote data store. Preferably, the medical data isstored at the remote data store in a directory corresponding to the datasource. In a preferred embodiment, the medical data at the remote datastore may be restored at the data source. Additionally, the medical dataat the remote data store may be copied to a second data source.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019]FIG. 1 illustrates a centralized remote data storage and retrievalsystem for archiving and restoring data in accordance with a preferredembodiment of the present invention.

[0020]FIG. 2 illustrates a flowchart for archiving data from a datasource at a remote data store in accordance with a preferred embodimentof the present invention.

[0021]FIG. 3 illustrates a flowchart for restoring data from a remotedata store to a data source in accordance with a preferred embodiment ofthe present invention.

[0022]FIG. 4 illustrates a flowchart for copying data from a remote datastore to a data source in accordance with a preferred embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

[0023]FIG. 1 illustrates a centralized remote data storage and retrievalsystem 100 for archiving and restoring data in accordance with apreferred embodiment of the present invention. The centralized remotedata storage and retrieval system 100 includes a plurality ofsubsystems, such as a data source 110, a remote data store 120, afront-end connection 130, a back-end connection 135, a status monitor140, and an access authenticator 145.

[0024] The front-end connection 130 connects the data source 110 to thestatus monitor 140 and the access authenticator 145. That is, thefront-end connection 130 facilitates communication between the datasource 110 and the status monitor 140 and the access authenticator 145.The back-end connection 135 connects the status monitor 140 and theaccess authenticator 145 to the remote data store 120. Preferably, thefront-end connection 130 and the back-end connection 135 compose a datasource/data store connection for bi-directional communication betweenthe data source 110 and the remote data store 120.

[0025] Preferably, the data source 110 is a picture archiving andcommunications system (PACS), a medical diagnostic imaging system, adatabase system, a computer system, a server, a hard disk drive, aterminal, or other medical data storage system, for example. Preferably,the data source 110 includes memory, such as a hard disk drive, a CD-ROMdrive, a DVD drive, a floppy disk drive, a tape drive, a ZIP drive, aRAM (Random Access Memory), and/or an other storage device, for example.The memory at the data source 110 preferably includes files, such asimages, reports, applications, and/or other data, for example. Files atthe data source 110 preferably are organized into at least onedirectory.

[0026] The data source 110 preferably also includes a processor capableof initiating at least one of several operation requests, such as anarchive request, a restore request, and/or a copy request. As furtherdescribed below, an archive request, for example, is a request to storedata at the remote data store 120. Additionally, a restore request, forexample, is a request to retrieve data stored at the remote data store120. Also, a copy request is a request to copy data stored by anotherdata source 115 at the remote data store 120 to the data source 110, forexample.

[0027] Preferably, the remote data store 120 is an application serviceprovider, but the remote data store 120 may be a server, a redundantdisk array, a RAID (Redundant Array of Independent Disks) drive, a harddisk drive, an archive, a database system, a computer system, or othercentral data storage system, for example. The remote data store 120 hasa capacity for data storage, such as a hard disk drive, a CD-ROM drive,a floppy disk drive, a tape drive, a ZIP drive, a RAM disk, and/or another storage device, for example. The data storage preferablyaccommodates files, such as images, reports, applications, and/or otherdata, for example. Preferably, the files in the remote data store 120are organized in directories corresponding to the data source 110.Preferably, the remote data store 120 also includes a processor capableof executing operations such as an archive operation, a restoreoperation, and/or a copy operation, for example. Additionally, theprocessor preferably may scan the directory of the data source 110. Theprocessor may also examine files at the data source 110 and/or theremote data store 120. In an alternative embodiment, the remote datastore 120 may be cached and stored at a plurality of locations.

[0028] In a preferred embodiment, the front-end connection 130 is aprivate network connection, such as a Digital Subscriber Line (DSL), aT1 line, an ISDN (Integrated Services Digital Network) line, an ATM(Asynchronous Transfer Mode) connection, a direct cable connection, orother private network, for example. Alternatively, the data source/datastore connection 130 may be a dial-up modem connection (that is, viatelephone line and computer modem), ethernet connection, the Internet,cable modem connection, wireless communication, a cable, a wire, orother network connection, for example. The front-end connectionfacilitates the bi-directional transmission and/or reception of files,commands, instructions, communication information, and/or other data,for example, between the data source 110 and the status monitor 140 andthe access authenticator 145.

[0029] In a preferred embodiment, the back-end connection 135 issubstantially similar to the front-end connection 130 described above.The back-end connection facilitates the bi-directional transmissionand/or reception of files, commands, instructions, communicationinformation, and/or other data, for example, between the remote datastore 120 and the status monitor 140 and the access authenticator 145.Preferably, the front-end connection 130 and the back-end connection 135compose a data source/data store connection to transfer data between thedata source 110 and the remote data store 120.

[0030] In a preferred embodiment, the status monitor 140 monitors thedata source 110, the remote data store 120, the front-end connection130, and/or the backend connection 135. That is, the status monitor 140monitors and/or controls activities such as requests by the data source110, requests by the remote data store 120, data at the data source 110,data at the remote data store 120, data travelling over the front-endconnection 130 and/or the back-end connection 135, commands and/orinstructions travelling over the front-end connection 130 and/or theback-end connection 135, for example. Preferably, the status monitor 140includes a processor to monitor the data source 110, the remote datastore 120, the front-end connection 130, and/or the back-end connection135. Preferably, the status monitor 140 may transmit commands and/orinstructions, for example, to the data source 110 and/or the remote datastore 120. Additionally, the status monitor 140 preferably may receivecommands and/or instructions, for example, from the data source 110and/or the remote data store 120.

[0031] The access authenticator 145 authenticates access of the remotedata store 120 by the data source 110. Additionally, the accessauthenticator 145 may authenticate access of the data source 110 by theremote data store 120. Preferably, the access authenticator 145 includesa predetermined authentication code or set of authentication codes (suchas a database or table of codes, for example). For example, the accessauthenticator 145 preferably includes an authentication code input by auser, an authentication code generated daily, an authentication codegenerated monthly, a randomly generated authentication key, and/or otherauthentication code, for example. The access authenticator may receivean authentication code, such as a password, identification number, orother authentication code, for example, from the data source 110, theremote data store 120, and/or the status monitor 140. Preferably, theauthentication code may be assigned according to an individual user, agroup of users, a type of data source, a location, and/or a function,for example.

[0032] In a preferred embodiment, the front-end connection 130 connectsthe data source 110 to the status monitor 140 and the accessauthenticator 145. Preferably, the back-end connection 135 connects theremote data store 120 to the status monitor 140 and the accessauthenticator 145. The status monitor 140 may connect to the accessauthenticator 145 via a network connection, such as the Internetethernet, direct cable connection, wireless, modem, wire, physicalconnection, or other network connection, for example. The location ofthe status monitor 140 with respect to the data source 110 and/or theremote data store 120 is not fixed. That is, the status monitor 140 maybe located at the data source 110, the remote data store 120, and/or theaccess authenticator 145. Additionally, the location of the accessauthenticator 145 with respect to the data source 110 and/or the remotedata store 120 is not fixed. That is, the access authenticator 145 maybe located at the data source 110, the remote data store 120, and/or thestatus monitor 140.

[0033] As mentioned above, the data source 110 preferably includes aprocessor capable of initiating at least one of several operationrequests, such as an archive request, a restore request, and/or a copyrequest. Each operation request is further discussed individually below.With respect to the archive operation request, the system 100 preferablyoperates as follows. First, data, such as an image or other medical datais obtained using medical diagnostic equipment and/or a healthcarepractitioner. The image may be an x-ray image, an ultrasound image, amagnetic resonance image, or a computerized tomography image, forexample. Other medical data may include examination reports, patientdemographic data, and/or scheduling data, for example. The image of apatient may be obtained using medical diagnostic equipment, such as anx-ray imaging system, a magnetic resonance imaging system, or acomputerized tomography imaging system, for example. For example, apatient visits a hospital for a computerized tomography (CT) scan, and atechnician obtains the image using a computerized tomography imagingsystem. Then, the data is stored at the data source 110. For example,the technician stores the CT image of the patient at a PACS at thehospital.

[0034] Preferably, the status monitor 140 detects the storing of thedata at the data source 110 via the front-end connection 130. Then, thestatus monitor 140 may prompt the data source 110 for an authenticationcode, which is discussed above. Next, the data source 110 transmits theauthentication code to the access authenticator 145 via the statusmonitor 140. Then, the access authenticator 145 compares the receivedauthentication code to the predetermined authentication code, which isdiscussed above. If the authentication code does not match thepredetermined authentication code, then access to the remote data store120 is not allowed. Alternatively, another attempt may be made to enteran authentication code. If the authentication code matches thepredetermined authentication code, then the status monitor 140 triggersan archive request to be sent to the remote data store 120 via theback-end connection 135. For example, the status monitor 140 detects thestorage of the computerized tomography image of the patient at the PACSand instructs the PACS to transmit the machine identification number ofthe PACS to the access authenticator 145. Then, for example, if themachine identification number matches an entry in the authenticationcode database of the access authenticator 145, the access authenticator145 allows the status monitor 140 to trigger an archive request to theremote data store 120.

[0035] Next, the remote data store 120 receives the archive request.Then, the remote data store 120 processes the request. Preferably, theremote data store 120 determines if a directory exists at the remotedata store 120 that corresponds to the data source 110. Then, the remotedata store 120 and/or the status monitor 140 may determine which filesfrom the data source 110 are up-to-date at the remote data store 120 andwhich files are to be transferred and stored at the remote data store120. For example, the remote data store 120 locates the directory forthe PACS at the remote data store 120. The status monitor 140, forexample, then determines that the new CT image is not in the PACSdirectory at the remote data store 120.

[0036] Next, the status monitor 140 preferably instructs the data source110 to transmit the data to be stored to the remote data store 120 viathe front-end connection 130 and the back-end connection 135. Forexample, the status monitor 140 transmits instructions to the PACSdirecting the PACS to transmit the CT image to the remote data store120. Then, the remote data store 120 archives the data sent by the datasource 110 at the remote data store 120. Preferably, the data isarchived at the remote data store 120 at the directory which correspondsto the data source 110. For example, the remote data store 120 storesthe CT image file from the PACS in the PACS directory at the remote datastore 120.

[0037] After the data is transferred between the data source 110 and theremote data store 120, the status monitor 140 may verify thetransmission and/or receipt of the data. That is, the status monitor 140may verify the transmission and/or receipt of the data by comparing filenames, file sizes, file time stamps, file checksums, data transmissioncodes, and/or error correction codes, for example. For example, thestatus monitor may verify the transfer of the CT image from the PACS tothe remote data store 120 by performing a cyclic redundancy check (CRC)on the data or by checking the parity bits of the transferred data, forexample, to insure that data was not lost or corrupted duringtransmission.

[0038] In an alternative embodiment, the archive request may betriggered after a definable interval, such as a timed interval, anevent-based interval, and/or another programmed interval. That is, atimed trigger may trigger an archive request hourly, daily, weekly,monthly, quarterly, and/or yearly, for example. For example, the PACSmay be programmed to request an archive operation at the end of everyday. Also, an event-based trigger may trigger an archive request afterdata is obtained, after data is saved, upon system shutdown, and/or uponprogram error, for example.

[0039] For a restore request, the system 100 preferably operates asfollows. First, data, such as an image or other medical data is obtainedand archived at the remote data store 120 as described above in relationto the archive operation. For example, an x-ray image of a patient and aradiology report for the patient are obtained and stored at a local PACSat a clinic. The image and report are then archived at the remote datastore 120 in a directory corresponding to the PACS.

[0040] In a preferred embodiment, an operation attempts to access thedata at the data source 110 and discovers an error in the data. Forexample, a user attempts to view the x-ray image and radiology report atthe PACS and discovers that the image and report have been corrupted.Alternatively, the data source 110 may automatically discover the errorin the data. Preferably, the status monitor 140 detects the error, suchas data loss, data corruption, and/or system failure, for example, atthe data source 110 via the front-end connection 130.

[0041] Then, the status monitor 140 may prompt the data source 110 foran authentication code, as discussed above. Next, the data source 110transmits the authentication code to the access authenticator 145 viathe status monitor 140. Then, the access authenticator 145 compares thereceived authentication code to the predetermined authentication code,as discussed above. If the authentication code does not match thepredetermined authentication code, then access to the remote data store120 is not allowed. Alternatively, another attempt may be made to enteran authentication code. If the authentication code matches thepredetermined authentication code, then the status monitor 140 triggersa restore request to be sent to the remote data store 120 via theback-end connection 135. For example, the status monitor 140 detectscorruption of the x-ray image at the PACS and instructs the PACS totransmit the monthly access password to the access authenticator 145.Then, for example, if the monthly access password matches the monthlypassword in the database of the access authenticator 145, the accessauthenticator 145 allows the status monitor 140 to trigger a restorerequest to the remote data store 120.

[0042] Next, the remote data store 120 receives the restore request.Then, the remote data store 120 processes the request. Preferably, theremote data store 120 determines if a directory exists at the remotedata store 120 that corresponds to the data source 110. Next, the remotedata store 120 determines if the lost and/or corrupted data is presentin the directory at the remote data store 120. If the data is notpresent in the directory at the remote data store 120, then the restoreoperation is halted. If the data is present in the directory at theremote data store 120, then the data may be retrieved. For example, theremote data store 120 locates the directory for the PACS at the remotedata store 120. Next, for example, the remote data store 120 determinesthat the x-ray image and the radiology report are stored at thedirectory for the PACS at the remote data store 120.

[0043] Next, the status monitor 140 preferably instructs the remote datastore 120 to transmit the data to be restored to the data source 110 viathe back-end connection 135 and the front-end connection 130. Forexample, the status monitor 140 transmits instructions to the remotedata store 120 directing the remote data store 120 to transmit the x-rayimage and radiology report to the PACS. Then, the data source 110restores the data sent by the remote data store 120 at the data source110. For example, the PACS stores the x-ray image file and radiologyreport from the PACS directory at the remote data store 120 at the PACS.

[0044] After the data is transferred between the remote data store 120and the data source 110, the status monitor 140 may verify thetransmission and/or receipt of the data. That is, the status monitor 140may verify the transmission and/or receipt of the data by comparing filenames, file sizes, file time stamps, file checksums, data transmissioncodes, and/or error correction codes, for example. For example, thestatus monitor may verify the transfer of the x-ray image and theradiology report from the remote data store 120 by performing a cyclicredundancy check (CRC) on the data or by checking the parity bits of thetransferred data, for example, to insure that data was not lost orcorrupted during transmission.

[0045] For a copy request, the system 100 preferably operates asfollows. First, data, such as an image or other medical data isobtained, stored at a data source 115, and archived at the remote datastore 120 as described above in relation to the archive operation. Forexample, an ultrasound image of a patient and an electrocardiogram (ECG)for the patient are obtained and stored at a local PACS at a clinic. Theimage and ECG are then archived at the remote data store 120 in adirectory corresponding to the PACS.

[0046] Preferably, the status monitor 140 detects the installation of anew data source 110, such as an upgraded data source or a replacementdata source, for example. Then, the status monitor 140 may prompt thedata source 110 for an authentication code, as discussed above. Next,the data source 110 transmits the authentication code to the accessauthenticator 145 via the status monitor 140. Then, the accessauthenticator 145 compares the received authentication code to thepredetermined authentication code, as discussed above. If theauthentication code does not match the predetermined authenticationcode, then access to the remote data store 120 is not allowed.Alternatively, another attempt may be made to enter an authenticationcode. If the authentication code matches the predeterminedauthentication code, then the status monitor 140 triggers a copy requestto be sent to the remote data store 120. For example, the status monitor140 detects the connection of a newer PACS to the system 100 for upgradeand instructs the newer PACS to transmit the secure identification keyto the access authenticator 145. Then, for example, if the secureidentification key from the newer PACS matches the secure identificationkey in the database of the access authenticator 145, the accessauthenticator 145 allows the status monitor 140 to trigger a copyrequest to the remote data store 120.

[0047] Next, the remote data store 120 receives the copy request. Then,the remote data store 120 processes the request. Preferably, the remotedata store 120 determines if a directory exists at the remote data store120 that corresponds to the data source 115. Then, the status monitor140 determines which data is to be copied to the data source 110. Next,the remote data store 120 determines if the data to be copied to thedata source 110 is present in the directory for the data source 115 atthe remote data store 120. For example, the remote data store 120locates the directory for the PACS at the remote data store 120. Thestatus monitor 140, for example, then determines that the ultrasoundimage and the ECG are to be copied to the newer PACS. Next, for example,the remote data store 120 determines that the ultrasound image and theECG are stored at the directory for the PACS at the remote data store120.

[0048] Next, the status monitor 140 preferably instructs the remote datastore 120 to transmit the data to be copied to the data source 110. Forexample, the status monitor 140 transmits instructions to the remotedata store 120 directing the remote data store 120 to transmit theultrasound image and ECG to the newer PACS. Then, the data source 110copies the data sent by the remote data store 120 at the data source110. For example, the newer PACS stores the ultrasound image file andECG from the PACS directory at the remote data store 120 at the newerPACS.

[0049] After the data is transferred between the remote data store 120and the data source 110, the status monitor 140 may verify thetransmission and/or receipt of the data. That is, the status monitor 140may verify the transmission and/or receipt of the data by comparing filenames, file sizes, file time stamps, file checksums, data transmissioncodes, and/or error correction codes, for example. For example, thestatus monitor may verify the transfer of the ultrasound image and theECG from the remote data store 120 by performing a cyclic redundancycheck (CRC) on the data or by checking the parity bits of thetransferred data, for example, to insure that data was not lost orcorrupted during transmission.

[0050] In an alternative embodiment, periodic copy operations may beexecuted to update the data source 110 with new data from the datasource 115. Alternatively, the entire contents of the data source 115may be copied to the data source 110 in a copy operation. In analternative embodiment, the data from the data source 115 is deletedfrom the remote data store 120 after the data is copied to the datasource 110.

[0051] In an alternative embodiment which may be applied to all of theabove disclosed embodiments, the system 100 may comprise a plurality ofdata sources 110, 115. If multiple data sources 110, 115 attempt toaccess the remote data store 120 and/or if a single data source 110, 115transmits multiple requests to the remote data store 120, the statusmonitor 140 may preferably arbitrate access to the remote data store120. The status monitor 140 may arbitrate access to the remote datastore 120 by allowing access to the remote data store 120 according tothe priority of the data source 110, 115. Priority may include systempriority, timing priority, or request priority, for example. Forexample, with system priority, a PACS may have a higher priority than anx-ray imaging system. With timing priority, for example, the systemwhich has been waiting for the longest amount of time has a higherpriority of access. For example, with request priority, a restorerequest may have a higher priority than a copy request. A data source110, 115 may wait for access to the remote data store 120 until accessis granted by the status monitor 140. For example, an ultrasound imagingsystem and an x-ray imaging system attempt to access the remote datastore 120. The x-ray imaging system, for example, has a higher systempriority than the ultrasound imaging system and is thus allowed toaccess the remote data store 120 first. The ultrasound imaging systemwaits for the remote data store 120 to complete the request of the x-rayimaging system and then the ultrasound imaging system may access theremote data store 120. Alternatively, the system 100 may accommodatemultiple requests and/or multiple data sources. Alternatively, thesystem 100 may arbitrate command execution rather than access.

[0052]FIG. 2 illustrates a flowchart 200 for archiving data from a datasource at a remote data store in accordance with a preferred embodimentof the present invention. The data source may be a picture archiving andcommunications system (PACS), a medical diagnostic imaging system, adatabase system, a computer system, a server, a hard disk drive, aterminal, or other data storage system, for example. The remote datastore may be an application service provider, a server, a redundant diskarray, a RAID drive, a hard disk drive, an archive, a database system, acomputer system, or other central data storage system, for example.

[0053] First, at step 210, data is obtained from a patient. Data mayinclude an image (such as an x-ray image, an ultrasound image, acomputerized tomography image, and/or a magnetic resonance image, forexample) and/or other medical data (such as examination reports,electrocardiograms, patient demographic data, and/or scheduling data,for example). Data may be obtained using medical diagnostic equipmentand/or examination by a healthcare professional, for example. Forexample, an x-ray image of a patient is obtained at a hospital. Next, atstep 220, the data is stored at the data source. For example, thepatient's x-ray image is stored in a PACS at the hospital.

[0054] Then, at step 230, an archive request is triggered. The archiverequest may be triggered by a status monitor, by the data source, and/orby the remote data source, for example. The request may preferably betriggered by programmed trigger and/or by manual trigger, for example.Preferably, a programmed trigger may trigger a request after a timeinterval (such as hourly, daily, monthly, yearly, etc.), an event (suchas file creation, data storage, system failure, program error, and/orsystem shutdown, for example), or other such definable interval. Forexample, the status monitor detects the storage of the x-ray image inthe PACS and triggers a request to archive the x-ray image.

[0055] Next, at step 240, the identity of the data source isauthenticated to verify that the data source may access the remote datastore. Preferably, authentication is facilitated using an authenticationcode, such as an authorization code, a personal identification number, amachine identification number, a password, or other identification code,for example. Preferably, the authentication code is transmittedautomatically by the data source or input by a user, for example, afterprompting by the status monitor. If the authentication code does notmatch a predetermined authentication code (such as a daily generatedcode, a monthly generated code, a random key, or other predeterminedauthentication code, for example), access is not granted. Alternatively,another attempt may be made to authenticate the access. If theauthentication code matches the predetermined authentication code, theauthentication code is verified, and access to the remote data store isauthorized. For example, the status monitor prompts a technician at thePACS to enter a password to access the remote data store. Then, forexample, the password is compared to the preset monthly password. If thetechnician's password matches the preset monthly password, the PACS mayaccess the remote data store.

[0056] Then, at step 250, if multiple data sources are attempting toaccess a single remote data store, access to the remote data store maybe arbitrated or controlled. Access arbitration may be facilitated byallowing access to the remote data store according to priority. Prioritymay include system priority, timing priority, or request priority, forexample. That is, system priority indicates that one system has a higherpriority of access than another system. Also, timing priority indicatesthat the system that has been waiting for access for the longest amountof time has a higher priority of access. Additionally, request prioritysignifies that certain operation requests may have a higher priority ofaccess than other operation requests. Preferably, data sources may waitfor access to the remote data store until access is granted throughaccess arbitration. For example, the PACS and an x-ray system attempt toaccess the remote data store. The PACS, for example, initiates theaccess before the x-ray system and thus is first in time. Therefore, forexample, the PACS is allowed to access the remote data store first. Thex-ray system, for example, waits for the remote data store to completethe archive request of the PACS and then may access the remote datastore. Alternatively, multiple accesses may be allowed at the remotedata store.

[0057] Next, at step 260, the data source is examined to determine whichdata is to be archived at the remote data store. The status monitor, thedata source, and/or the remote data store may determine which data isnew or updated data to be archived at the remote data store and whichdata has already been archived at the remote data store. For example,the status monitor examines the directory of the PACS and locates thenew x-ray image file to be archived at the remote data store.Alternatively, all data at the data source may be selected for archivingat the remote data store. Additionally, a user at the data source maymanually select the data to archive at the remote data store (such as byclicking on file names in a backup program, for example).

[0058] Then, at step 270, the data is transferred from the data sourceto the remote data store. That is, files stored at the data source aretransmitted to the remote data store. Preferably, the remote data storeincludes a directory, for example, in which to archive data from thedata source. Alternatively, the remote data store includes a hard diskdrive and/or other storage area, for example, in which to archive datafrom the data source. In the event of an archive request, data may betransferred from the data source to the directory, for example, of theremote data store to backup data and provide data reliability andsecurity, for example. For example, the x-ray image file is transferredfrom the PACS to a directory at the remote data store which correspondsto the PACS. Data may be transmitted on a file-by-file basis, on adisk-by-disk basis, on a data block-by-data block basis, or on abit-by-bit basis, for example.

[0059] Next, at step 280, the transfer of data between the data sourceand the remote data store is verified. That is, the data transfer may beverified by comparing file names, file sizes, file time stamps, filechecksums, data transmission codes, and/or error correction codes, forexample. For example, the status monitor may verify the transfer of thex-ray image file from the PACS to the remote data store by performing acyclic redundancy check (CRC) on the file or by checking the parity bitsof the transferred data, for example, to insure that data was not lostor corrupted during transmission.

[0060] Finally, at step 290, the triggered request is reset so that anew request may be triggered. For example, the status monitor signal toinitiate an archive operation is reset to normal upon completion of thebackup and verification that the PACS data has been archived at theremote data store.

[0061]FIG. 3 illustrates a flowchart 300 for restoring data from aremote data store to a data source in accordance with a preferredembodiment of the present invention. First, data is obtained andarchived at the remote data store in a method substantially similar tothat described above in relation to FIG. 2. The data is preferablyarchived at the remote data store in a directory corresponding to thedata source, as described above. Then, at step 310, an error occurs atthe data source. The error may include data loss, data corruption,system failure, program error, and/or power loss, for example. Forexample, an x-ray image is corrupted in a PACS and is unviewable.

[0062] Then, at step 320, a restore request is triggered. The restorerequest may be triggered by a status monitor, by the data source, and/orby the remote data source, for example. The request may preferably betriggered by programmed trigger and/or by manual trigger, for example.Preferably, a programmed trigger may trigger a request after an event,such as system failure, data corruption, data loss, and/or programerror, for example, occurs. For example, a user attempts to access thex-ray image at the PACS and discovers that the x-ray image is corrupted.The status monitor, for example, detects the corrupted x-ray image inthe PACS and triggers a request to restore the x-ray image.

[0063] Next, at step 330, the identity of the data source isauthenticated to verify that the data source may access the remote datastore. Preferably, authentication proceeds as described above inreference to FIG. 2. For example, the status monitor prompts atechnician at the PACS to enter a password to access the remote datastore. Then, for example, the password is compared to the preset monthlypassword. If the technician's password matches the preset monthlypassword, the PACS may access the remote data store.

[0064] Then, at step 340, if multiple data sources are attempting toaccess a single remote data store, access to the remote data store maybe arbitrated or controlled. Access arbitration may be facilitated byallowing access to the remote data store according to priority, asdescribed above in reference to FIG. 2. Preferably, data sources maywait for access to the remote data store until access is granted throughaccess arbitration. For example, the PACS and an x-ray system attempt toaccess the remote data store. The restore request of the PACS, forexample, has a higher priority than the archive request of the x-raysystem, and, thus, the PACS is allowed to access the remote data storefirst. The x-ray system, for example, waits for the remote data store tocomplete the restore request of the PACS and then may access the remotedata store. Alternatively, multiple accesses may be allowed at theremote data store.

[0065] Next, at step 350, the data source is examined to determine whichdata is to be restored from the remote data store. The status monitor,the data source, and/or the remote data store may determine which datais lost or corrupted data to be restored at the data source and whichdata is already present at the data source. For example, the statusmonitor examines the directory of the PACS and locates the corruptedx-ray image file to be restored. Alternatively, a user at the datasource may manually select the data to restore from the remote datastore (such as by clicking on file names in a restore program, forexample).

[0066] Then, at step 360, the data is transferred from the remote datastore to the data source. That is, files stored at the remote data storeare transmitted to the data source. Preferably, the remote data storeincludes a directory, for example, which contains data from the datasource. Alternatively, the remote data store includes a hard disk driveand/or other storage area, for example, which contains data from thedata source. In the event of a restore request, data may be transferredfrom the directory, for example, of the remote data store to the datasource. For example, the x-ray image file is transferred to the PACSfrom the directory at the remote data store which corresponds to thePACS. Data may be transmitted on a file-by-file basis, on a disk-by-diskbasis, on a data block-by-data block basis, or on a bit-by-bit basis,for example. Preferably, the data is not deleted from the remote datastore after transfer and may be used again to restore at the data source110.

[0067] Next, at step 370, the transfer of data between the remote datastore and the data source is verified. That is, the data transfer may beverified by comparing file names, file sizes, file time stamps, filechecksums, data transmission codes, and/or error correction codes, forexample. For example, the status monitor may verify the transfer of thex-ray image file from the remote data store to the PACS by performing acyclic redundancy check (CRC) on the file or by checking the parity bitsof the transferred data, for example, to insure that data was not lostor corrupted during transmission.

[0068] Finally, at step 380, the triggered request is reset so that anew request may be triggered. For example, the status monitor signal toinitiate a restore operation is reset to normal upon completion of therestore and verification that the data has been restored at the PACS.

[0069]FIG. 4 illustrates a flowchart 400 for copying data from a remotedata store to a data source in accordance with a preferred embodiment ofthe present invention. First, data is obtained from a first data sourceand archived at the remote data store in a method substantially similarto that described above in relation to FIG. 2. The data is preferablyarchived at the remote data store in a directory corresponding to thefirst data source, as described above. Then, at step 410, a second datasource is installed. That is, an additional, upgraded, and/orreplacement data source may be added along with or in place of the firstdata source. For example, a hospital upgrades their data storagecapabilities and installs a new PACS to replace the old PACS.

[0070] Then, at step 420, a copy request is triggered. The copy requestmay be triggered by a status monitor, by the first data source, by thesecond data source, and/or by the remote data source, for example. Therequest may preferably be triggered by programmed trigger and/or bymanual trigger, for example. Preferably, a programmed trigger maytrigger a request after an event (such as system start-up, systeminstallation, and/or connection to the network, for example), or othersuch definable interval. For example, the status monitor detects thepresence of the new PACS and triggers a request to copy the data fromthe old PACS to the new PACS.

[0071] Next, at step 430, the identity of the second data source isauthenticated to verify that the second data source may access theremote data store. Preferably, authentication proceeds as describedabove in reference to FIG. 2. For example, the status monitor prompts atechnician at the new PACS to enter a password to access the remote datastore. Then, for example, the password is compared to the preset monthlypassword. If the technician's password matches the preset monthlypassword, the new PACS may access the remote data store.

[0072] Then, at step 440, if multiple data sources are attempting toaccess a single remote data store, access to the remote data store maybe arbitrated or controlled. Access arbitration may be facilitated byallowing access to the remote data store according to priority, asdescribed above in reference to FIG. 2. Preferably, data sources maywait for access to the remote data store until access is granted throughaccess arbitration. For example, the new PACS and an x-ray systemattempt to access the remote data store. The PACS, for example, has ahigher system priority than the x-ray system, and, thus, the PACS isallowed to access the remote data store first. The x-ray system, forexample, waits for the remote data store to complete the copy request ofthe PACS and then may access the remote data store. Alternatively,multiple accesses may be allowed at the remote data store.

[0073] Next, at step 450, the remote data store is examined to determinewhich data is to be copied from the remote data store to the second datasource. The status monitor, the data source, and/or the remote datastore may determine which data is to be copied from the remote datastore to the second data source and which data is already present orunnecessary at the second data source. Preferably, the remote data storeincludes a directory, for example, which contains data from the firstdata source. Alternatively, the remote data store may include a harddisk drive and/or other storage area, for example, which contains datafrom the first data source. Thus, the directory, for example, whichcontains data from the first data source may be examined to determinedwhich data is to be copied to the second data source. For example, thestatus monitor examines the directory of the remote data store andlocates the directory containing files from the old PACS. Alternatively,a user at the data source may manually select the data to copy from theremote data store (such as by clicking on file names in a copy program,for example).

[0074] Then, at step 460, the data is transferred from the remote datastore to the second data source. That is, files stored at the remotedata store are transmitted to the second data source. In the event of acopy request, data may be transferred from the directory, hard diskdrive, and/or storage area, for example, of the remote data store whichcorresponds to the first data source to the second data source. Forexample, data in the directory of the remote data store corresponding tothe first data source is transferred to the second data source. Data maybe transmitted on a file-by-file basis, on a disk-by-disk basis, on adata block-by-data block basis, or on a bit-by-bit basis, for example.Preferably, the data is not deleted from the remote data store after thedata is copied to the second data source.

[0075] Next, at step 470, the transfer of data between the remote datastore and the second data source is verified. That is, the data transfermay be verified by comparing file names, file sizes, file time stamps,file checksums, data transmission codes, and/or error correction codes,for example. For example, the status monitor may verify the transfer ofthe files from the remote data store to the PACS by performing a cyclicredundancy check (CRC) on the file or by checking the parity bits of thetransferred data, for example, to insure that data was not lost orcorrupted during transmission.

[0076] Finally, at step 480, the triggered request is reset so that anew request may be triggered. For example, the status monitor signal toinitiate a copy operation is reset to normal upon completion of the copyoperation and verification that the data has been copied to the newPACS.

[0077] In an alternative embodiment, periodic copy operations may beexecuted to update the second data source with new data from the firstdata source. Alternatively, the entire contents of the first data sourcemay be copied to the second data source in a copy operation. In analternative embodiment, the data from the first data source is deletedfrom the remote data store after the data is copied to the second datasource.

[0078] Thus, the preferred embodiments of the present invention providecentralized archiving and retrieval of medical data via a remote datastore. That is, a data source may archive data at the remote data storeand retrieve the data in the event of a system failure, file corruption,or data loss, for example. Additionally, the preferred embodimentsprovide for retrieval of data from a central remote data store atmultiple locations. For example, a first hospital with a first PACS mayarchive the data from the first PACS at the remote data store. Then, asecond hospital with a second PACS may copy the data from the remotedata store onto the second PACS. Thus, the files may be reliablyretrieved and accessed at a variety of locations via the remote datastore.

[0079] Thus, the preferred embodiments allow reliable access to medicaldata by providing a remote data store to archive data from a data sourceand restore data at the data source. That is, in the event of data lossand/or corruption, the data may be restored at the data source by theremote data store. Additionally, in the event of a system failure, thedata at the remote data store may be copied to a replacement system.Thus, the preferred embodiments provide reliable access to medical datato aid in the diagnosis and treatment of patients by helping to insurethat data is available so that healthcare practitioners may use the datato aid in the diagnosis and treatment of patients.

[0080] While the invention has been described with reference to apreferred embodiment, it will be understood by those skilled in the artthat various changes may be made and equivalents may be substitutedwithout departing from the scope of the invention. In addition, manymodifications may be made to adapt a particular situation or material tothe teachings of the invention without departing from its scope.Therefore, it is intended that the invention not be limited to theparticular embodiment disclosed, but that the invention will include allembodiments falling within the scope of the appended claims.

What is claimed is:
 1. A central data archiving system, said systemcomprising: a data source providing medical data; a status monitor forcontrolling the transfer of said medical data from said data source to aremote data store; and a remote data store receiving said medical dataand storing said medical data.
 2. The system of claim 1, wherein saidstatus monitor verifies said transfer of said medical data from saiddata source to said remote data store.
 3. The system of claim 1, furthercomprising an access authenticator for authenticating access to saidremote data store by said data source.
 4. The system of claim 3, whereinsaid access authenticator authenticates access to said data source. 5.The system of claim 1, wherein said data source further stores medicaldata.
 6. The system of claim 5, wherein said remote data store furtherrestores said medical data to said data source.
 7. The system of claim1, wherein said remote data store stores a copy of said medical data. 8.The system of claim 1, further comprising a second data source forstoring medical data, wherein said remote data store transfers saidmedical data to said second data source.
 9. The system of claim 1,wherein said remote data store comprises an application serviceprovider.
 10. The system of claim 1, wherein said remote data store isstored at a plurality of locations.
 11. The system of claim 1, whereinsaid status monitor controls the transfer of data from said data sourceto said remote data store at a definable interval.
 12. The system ofclaim 11, wherein said definable interval comprises a timed interval.13. The system of claim 11, wherein said definable interval comprises anevent-based interval.
 14. The system of claim 11, wherein said definableinterval comprises a manual interval.
 15. A system for remotelyaccessing a centralized data store, said system comprising: a remotedata store storing medical data; a status monitor for controlling thetransfer of said medical data from said remote data store to a datasource; and a data source receiving said medical data and storing saidmedical data.
 16. The system of claim 15, further comprising a seconddata source storing medical data.
 17. The system of claim 16, whereinsaid status monitor controls the transfer of said copy of said medicaldata between said remote data store and said second data source.
 18. Thesystem of claim 16, wherein said status monitor verifies the transfer ofsaid copy of said medical data between said remote data store and saidsecond data source.
 19. The system of claim 15, further comprising anaccess authenticator for authenticating access to said remote datastore.
 20. The system of claim 15, wherein said status monitor verifiessaid transfer of said medical data between said first data source andsaid remote data store.
 21. The system of claim 15, wherein said remotedata store comprises an application service provider.
 22. The system ofclaim 15, wherein said remote data store is stored at a plurality oflocations.
 23. The system of claim 15, wherein said remote data storerestores said medical data at said data source.
 24. The system of claim15, wherein said remote data store comprises at least one directorycorresponding to said first data source.
 25. A method for remotelyarchiving medical data, said method comprising: transferring saidmedical data from a data source to a remote data store; and storing saidmedical data at said remote data store.
 26. The method of claim 25,further comprising the step of obtaining said medical data.
 27. Themethod of claim 25, further comprising the step of storing said medicaldata at said data source.
 28. The method of claim 25, wherein saidstoring step further comprises storing said medical data at said remotedata store in a directory corresponding to said data source.
 29. Themethod of claim 25, wherein said transferring step further comprisesverifying said transfer of medical data from said remote data store tosaid data source.
 30. The method of claim 25, further comprising thestep of authenticating access to said remote data store.
 31. The methodof claim 25, wherein said transferring step occurs after a definableinterval.
 32. The method of claim 31, wherein said definable intervalcomprises a timed interval.
 33. The method of claim 31, wherein saiddefinable interval comprises an event-based interval.
 34. The method ofclaim 31, wherein said definable interval comprises a manual interval.35. The method of claim 25, further comprising the step of restoringsaid medical data to said data source from said remote data store. 36.The method of claim 25, further comprising the step of copying saidmedical data from said remote data source to a second data source.
 37. Amethod for restoring medical data to a data source from a remote datastore, said method comprising: detecting an error in accessed medicaldata; transferring a copy of said medical data from a remote data storeto said data source; and restoring said medical data by replacing saidmedical data at said data source with said copy of said medical data.38. The method of claim 37, further comprising the step of previouslyobtaining said medical data at said data source and storing said medicaldata at said remote data store.
 39. The method of claim 37, furthercomprising the step of copying said medical data to a second datasource.
 40. The method of claim 37, wherein said transferring stepfurther comprises verifying said transferring of medical data from saidremote data store to said data source.
 41. The method of claim 37,further comprising the step of authenticating access to said remote datastore.
 42. The method of claim 37, wherein said transferring stepfurther comprises transferring said medical data from a directoryrepresentative of said data source at said remote data store to saiddata source.
 43. A method for installing medical data from a first datasource to a second data source, said method comprising: storing dataremotely from a first data source to a remote data store; providingaccess to a second data source; transferring said medical data from saidremote data store to said second data source; and storing said medicaldata at said second data source.
 44. The method of claim 43, whereinsaid transferring step further comprises transferring said medical datafrom a directory representative of said first data source at said remotedata store to said second data source.
 45. The method of claim 43,wherein said transferring step further comprises transferring files ofmedical data from said remote data store to said second data store. 46.The method of claim 43, wherein said transferring step further comprisestransferring the entire contents of said first data source from saidremote data store to said second data source.
 47. The method of claim43, wherein said transferring step further comprises verifying saidtransferring of medical data from said remote data store to said seconddata source.
 48. The method of claim 44, further comprising the step ofauthenticating access to said remote data store.
 49. The method of claim44, wherein said transferring step occurs after a definable interval.50. The method of claim 49, wherein said definable interval comprises atimed interval.
 51. The method of claim 49, wherein said definableinterval comprises an event-based interval.
 52. The method of claim 49,wherein said definable interval comprises a manual interval.